Fix Class MMBackend duplication bug on launch#834
Conversation
This issue was detected on both Homebrew and Github released MacVim for v8.1 on a fresh install of OS High Sierra with no .vim or .vimrc configuration Basically, when starting vim from the command line, it produces the following error: ``` objc[4513]: Class MMBackend is implemented in both /usr/local/Cellar/macvim/8.1-153/MacVim.app/Contents/bin/../MacOS/Vim (0x10b303f38) and /usr/local/Cellar/macvim/8.1-153/MacVim.app/Contents/MacOS/Vim (0x217f5bf38). One of the two will be used. Which one is undefined. ``` If launching graphical interface, the error shows up twice. The issue was traced to the use of '/../' in the binary path for launching the application which somehow pollutes the library path for the executable, finding copies of the MMBackend class in both the absolute path and the quazi-relative path. To resolve this, the relative component was removed from the path resolution of the actual Vim binary by actually dropping down a directory from the script location. It also simplifies the dereferencing of any link chains to that script.
|
Your change seems ok, but now I don't remember if I have seen this error before and why no one has complained about it. Does MacVim still run when you see the error? My laptop is actually under repair so I won't be able to get to this PR and try it out for a week or two. |
|
MacVim does still run when you see the error, but it pollutes the terminal and potentially interferes with automation. I have seen various hits on Google that were slightly different than this, relating to python versions and interactions with plugins, but this was encountered on a "fresh" OS and Homebrew install with no plug ins. I say "fresh" because it is a corporate laptop, with whatever policies and apps they have put on it. I'm not sure the exact mechanics that causes it to fail, but my reasoning for pursuing this is that the patch does not add any complexity to the code (actually simplifies the code and path) so follows the Hippocratic "first do no harm" rule while solving an admittedly rare problem. I have tested this on both the machine that is having the problem and a machine that isn't having this problem (both High Sierra). As an alternative, I'd love to understand why this is picking up the quazi-relative path and the absolute path when the binary is called. I'm not an objective-C developer, but if you have anything you'd like me to try to debug what's happening I'd be happy to do so. As for waiting a week or two for you, I'm in no rush -- I just wanted to be a good OSS citizen and contribute back to a project that I love and used for years. I figured if I had a fix, I might as well share it in case anyone else ran into it. |
|
Ok I have merged your changes! I couldn't repro the issue you reported though, but I do remember seeing it before. It could be because I upgraded to Mojave, or other reasons. If you have more insight on how you are launching |
2 participants
This issue was detected on both Homebrew and Github released MacVim for v8.1 on a fresh install of OS High Sierra with no .vim or .vimrc configuration
Basically, when starting vim from the command line, it produces the following error (from homebrew -- similar with different paths for Github release version):
If launching graphical interface, the error shows up twice.
The issue was traced to the use of '/../' in the binary path for launching the application which somehow pollutes the library path for the executable, finding copies of the MMBackend class in both the absolute path and the quazi-relative path.
To resolve this, the relative component was removed from the path resolution of the actual Vim binary by actually dropping down a directory from the script location. It also simplifies the dereferencing of any link chains to that script.